Expectation Rubrics
Learn how using expectation rubrics clarifies expectations for your employees, you, and your peer managers.
We'll cover the following
In many cases, you will be asked to hold somebody accountable to an expectation that you (and/or your employees) don’t find particularly clear. Perhaps it’s the “writes good code” example mentioned earlier, or it’s something like “communicates clearly with senior executives.” Although the best scenario would be to rewrite the expectation to be more clear and/or objective, doing so often requires pretty serious effort. Rewriting expectations for a Software Engineer on your team often means you’re changing the expectations in the HR system for all Software Engineers, and other managers throughout the company are going to have opinions on what that should look like. (Perhaps you will be unsurprised to learn that writing good job expectations across a company of thousands of engineers is not easy.)
The next step, then, is to create a rubric for a position’s expectations: an answer key, if you will, that describes what you expect to see—actions and behaviors—for each of the expectations. The rubric should be as objective as possible: the actions and behaviors should be observable, related directly to the heart of the expectation, and organized into “levels” that correspond with a “grade” or “acceptability” that corresponds to the larger performance review system.
Example of an expectation rubric#
For example, let's assume you work for a company that uses a three-level performance review system: for any given expectation, employees are "Exceeding expectations," "Meeting expectations," or receiving a "Needs improvement." (Note that I'm not advocating such a scale, just using this as an example. Some companies will prefer a four- or five-tiered system, some will look to use a 10-point scale, and so on.)
Then, for an expectation of "Writes good code," we might create a rubric that looks like the following (for the code written by this individual):
Exceeds expectations. Code is well-organized: each method does one and only one thing, methods are named correctly, and length is less than 20 lines in length. Engineers who have never seen the code before can look at the code and understand it well enough to offer up a description of its implementation in less than an hour's worth of review. Comments provide implementation insight, rather than just restate the obvious.
Meets expectations. Code solves the problem it sets out to solve, but it could be optimized: it uses a brute-force algorithm instead of something more efficient, it creates a number of temporary objects that could be removed, and so on. Other team members reviewing the code have questions about its implementation after less than an hour's worth of review.
Needs improvement. Code contains numerous violations of DRY (don't repeat yourself) or SOLID principles. Implementation does not conform to our coding conventions and/or requires significant fixes. Code contains comments that are either redundant or recursive (A says to see B, B says to see A), or comments are missing. Other engineers require much more than an hour to understand anything about the code.
Again, this is only an example of a rubric, and one that stresses the organization and "communicative" capabilities of the code. For another team that ships libraries for high-performance calculation scenarios, the rubric would probably need to contain performance-related evaluation elements.
When creating a rubric, one way to ascertain its utility is to ask a peer manager to use the rubric in an informal way to evaluate somebody on your team or their team. Think of it as a unit-test. Take an employee who fits your intuitive understanding of a particular level ("Matt is an exceeds-expectations engineer"), and ask your peer to use the rubric to examine that individual's performance. "Hey, Kim, would you mind taking some of Matt's code and running it through my rubric and give me your results?" If your peer can use the rubric and come to the same result you would, there's a good chance the rubric is serving its intended purpose.
Attributes and Examples of Clear Expectations
Expectations vs. Goals